1. Field of the Invention
The present invention relates to operating systems for controlling the operations of digital computers. More particularly, the present invention relates to microkernel operating systems that segregate kernel functions from operating systems personality and applications. Still more particularly, the present invention provides generic microkernel semaphores that allow concurrent semaphore management by emulating multiple operating system semaphore interfaces.
2. Background and Related Art
Existing computer operating systems provide synchronization primitives frequently called semaphores for controlling access to system resources and synchronizing the activities of multiple processes. Synchronization primitives of each operating system are unique to that operating system even though they implement similar functionality. A microkernel operating system, such as the IBM microkernel, provides basic system function to support multiple operating system personalities. This permits application programs written for different operating systems to concurrently operate with each invoking interfaces of its home operating system. The IBM microkernel, therefore, must provide synchronization primitives that support synchronization primitives of the other operating systems. Without such generality, resource synchronization will be limited to synchronization within one particular operating system which may fail to provide adequate support across multiple operating system personalities.
A second problem is that application developers have learned to use a programming style for synchronization from a particular operating system. Retention of operating systems specific synchronization interfaces enables those programmers to continue development without learning a new microkernel based synchronization mechanism.
Operating systems typically divide synchronization primitives into two areas: locking and waiting.
Locking is used to protect shared resources from parallel or concurrent access by more than one thread. The resources that are locked are usually data structures, but they can be anything including files, devices, etc. Typically, but not always, the resources are held for a short duration so threads that need access to the resource usually don""t have to wait to acquire the protecting lock. Locking primitives range from the simple mutex (which can only be acquired in the exclusive mode) to those that distinguish between different types of access such as access for read only, or access for read and write.
Waiting primitives are used to suspend execution until some event occurs. Typically the wait is of long or unbounded duration. Waiting is frequently used to synchronize operations performed by multiple threads within a single process. For example, one thread may need to wait until the operation performed by a related thread is complete.
Modern operating systems often implement a semaphore as a condition variable. Condition variables are used to wait for events to happen. Condition variables work in conjunction with locks to wait for the events while allowing other threads to enter the critical section protected by the lock. This combination is used to implement monitors and experience has shown that fewer programming mistakes are made with condition variables than with semaphores. Condition variables must be coded inside a while loop that tests for the event or condition. As a result, the waiting thread is the one ensuring that the condition is true before proceeding. When semaphores are used, it is the signaler that must ensure that the condition will be true when the waiter is rescheduled. This can lead to subtle programming errors.
The traditional semaphore was proposed by Dijkstra and constitutes a non-negative value (The Logical Design of Operating Systems, L. Bic and A. C. Shaw, 1988, which references xe2x80x9cCooperating Sequential Processesxe2x80x9d, E. W. Dijkstra, Mathematics Depts., Technological University, Eindhoven, The Netherlands.) Dijkstra semaphores have only two operations: P and V. The P operation causes a wait until the semaphore is positive then decrements its value by one. The V operation increments the value of the semaphore by one.
Other authors have changed the number and character of operations allowed on semaphores. Operating systems have also changed the character and types of operations allowed on semaphores. Today there are a surprising variety in the types of operations that can be performed on semaphores. Programming books often have entire sections or chapters explaining the subtleties of how a semaphore works on a specific operating system.
The use of synchronization mechanisms in microkernel based operating systems are discussed in U.S. Pat. No. 5,519,867 entitled xe2x80x9cObject-Oriented Multitasking Systemxe2x80x9d, to Moeller et al and U.S. Pat. No. 5,475,845 entitled xe2x80x9cWrapper System for Interfacing to an Object-Oriented Application to a Procedural Applicationxe2x80x9d, to Orton et al. These patents describe the Taligent Operating System that employs the Mach Microkernel from Carnegie Mellon University. They describe the requirement for synchronization and the need to provide synchronization primitives or semaphores in an operating system. These patents describe the use of standard semaphores for a single operating system but provide no teaching of an ability to support multiple operating system semaphore architectures by a single microkernel based semaphore system.
Low level synchronization primitives are described in the IBM Technical Disclosure Bulletin entitled xe2x80x9cMicrokernel Synchronization Primitivesxe2x80x9d, Volume 38, No. 5, May 1995, pp. 283-291. These primitives support the implementation of semaphores such as those disclosed herein but provide no application level interfaces that map to existing operating system syntax.
IBM Technical Disclosure Bulletin entitled xe2x80x9cMicrokernel Semaphoresxe2x80x9d, Volume 38, No. 7, July 1995 pages 111-117, describes basic semaphore support in the IBM microkernel. However, these semaphore operations provide a single operating system based implementation that do not allow the emulation of semaphore operations provided by other operating systems.
The technical problem therefore remains of providing a generic semaphore operation that supports semaphores from multiple operating system personalities and in an efficient manner that is transparent to those personalities.
The present invention is directed to providing a generic semaphore operation that is able to emulate and respond to semaphore API""s from multiple operating system personalities. Semaphore operations of the present invention allow concurrent resource control and process synchronization from multiple operating system personalities. This enables a single resource to be used by applications using different operating system personalities.
It is therefore an object of the present invention to provide a single set of semaphore operations that emulate and support multiple concurrent operating systems.
It is yet another object of the present invention to provide efficient semaphore operations that do not require significant overhead to process.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention, as illustrated in the accompanying drawing wherein like reference numbers represent like parts of the invention.